所以，你正在进行一个活动，并从某个联盟网络或产品销售中获得转化，但转化并没有在FunnelFlux中显示出来。
在这里，我将分解一些故障排除步骤 - 一个需要遵循的思考过程。
首先，你是如何触发转化的？
有两个选项 - 使用回传URL（服务器对服务器），或JavaScript。让我们来看看这两种转化流程。
通过回传URL进行转化
如果你通过回传URL跟踪转化，需要成功完成以下几个步骤：
- 你需要通过重定向将用户发送到一个offer页面 - 即由FunnelFlux生成的跟踪链接或动作点击链接
- 该offer页面需要在其URL中传递我们的hit ID，使用
{hit}标记，你可能会在offer源的数据传递部分配置这个 - 网络/offer平台需要捕获并存储该hit ID值
- 网络/offer平台之后需要向FunnelFlux发送一个回传，传递那个存储的值。
所有这些步骤都需要正确运作，回传才能触发转化。
让我们来看看每个步骤中的一些常见问题。
将用户发送到offer页面
你在FunnelFlux中添加了一个offer，将用户发送到某个网络/广告商或者你控制的offer页面。
以下是一些需要考虑的事项：
- 你是否使用的是offer而不是落地页？落地页不会创建可以直接转化的点击
- 在你的漏斗中，如果你使用一个链接到offer的落地页，你是否在页面上为点击使用了动作URL？如果没有，它将不会通过跟踪器重定向，也不会传递hit ID
- 如果你使用我们的重定向链接从广告 > offer进行链接，那么你就会全程重定向 - 所以这里没问题
- 但为了万无一失...你是否在你的广告中使用FunnelFlux URL，而不是offer URL本身？
接下来，向offer/广告商传递数据
现在，让我们考虑向offer本身传递数据。
在数据传递部分（理想情况下），你传递的某个参数 = 我们的跟踪ID，它有{hit}标记
你可以通过编辑offer --> 数据传递选项卡来检查数据传递是否按预期进行。在这里你可以看到从offer源继承的数据传递，直接在offer上的数据传递，以及我们系统将重定向到的最终结果URL：
- 你是否确实将{hit}传递给了网络/广告商？这应该在数据传递部分。我们需要将这个offer的hit ID传递给下一个系统，这个ID是在重定向时创建的（直到我们尝试加载offer本身之前它是不存在的）
- 该hit是否以网络平台使用和捕获数据的参数名传递，如clickid、s5、aff_sub3等？
- 如果你进入网络平台和他们的点击报告，你能否通过该参数进行报告并看到来自FunnelFlux的hit ID？如果它们是offer点击，它们总是以"h"结尾
- 有时网络不允许你通过点击ID进行报告。但如果你可以通过这个参数进行报告，你应该能看到我们的hit ID传入。如果你看不到它们，那么网络就没有这些ID，他们也就无法向FunnelFlux发送转化 - 你需要修复一个数据传递问题。
向FunnelFlux的回传
让我们假设数据传递工作正常，但你仍然没有在FunnelFlux中看到转化。考虑以下几点：
- 你传递给网络的hit ID - 检查它们是否以"h"结尾，这表明它们是offer点击而不是落地页点击
- 你的全局回传URL可以在系统设置中找到。它的格式如下：
https://DOMAIN/pb/?hit=HIT_ID&rev=REVENUE&tx=OPTIONAL_TXID
- 你是否使用的是这个？确保HIT_ID占位符被像{click_id}这样的标记替换，网络将动态地用该用户的传递hit ID替换它
- 确保
REVENUE被某个数值或像#payout#这样的标记替换，网络将用真实的转化值替换它 - 回传URL中有没有任何拼写错误？缺少
?或&可能导致无效的语法和完全无法工作的URL - 如果有疑问，你可以要求我们查看我们的传入回传日志，看看我们收到了什么以及为什么它可能不起作用
这就是基于回传的跟踪的所有故障排除。它完全依赖于从一个系统到另一个系统的数据传递和正确使用标记。
如果这个过程中有任何不正确的地方，比如URL损坏、没有传递ID或设置回传URL不正确，那么转化就不会出现。
这些系统是程序化和明确的，所以它们无法解释你的错误并修复它们，它们只会简单地不做你期望的事情。
通过JavaScript进行转化
通过JavaScript跟踪转化是完全不同的，因为不需要从系统A到B的显式数据传递，而且重要的是，它发生在客户端。
回传URL是"服务器端"跟踪，因为不是转化用户发送转化请求。但使用JavaScript，它在用户的浏览器中加载，并将依赖于那个浏览器中的上下文。
因此，它本质上不太可靠 - 用户的浏览器环境差异很大，有许多东西会妨碍跟踪，比如浏览器标准、隐私限制、广告拦截插件，当然还有 - 用户做的奇怪的事情。
以下是你通常如何使用JavaScript进行跟踪：
- 在所有涉及的页面上放置我们的全局头部JS
- 在每个页面上放置查看跟踪JS，因为你想跟踪查看，而且它有帮助函数来改善整体跟踪（很重要！）
- 当你想转化特定offer时，转到编辑该offer > 转化跟踪 > 获取转化跟踪代码
- 将该代码放在你想触发转化的地方 - 这通常会是实际offer之后的感谢页面，如果你有技术技能，你也可以手动执行脚本
很典型 - 但有很多原因可能导致这不起作用，而且很多都归结于浏览器的细微差别和问题。让我们回顾一些导致这种跟踪失败的主要原因。
问题1：你的JavaScript实际上没有正确加载
要加载转化代码，你仍然需要在页面上在转化脚本之前放置我们的全局头部JS。
如果你没有它，确保添加它。它在任何页面上应该只出现一次。
如果你只能在页面上放置一个代码块，只需将它放在转化代码之前。理想情况下它应该在<head>中，但这不是关键，它只需要先出现。
如果你想更具体地测试，你可以打开浏览器的Web开发者工具 > 网络选项卡，清除所有内容然后刷新页面并查看我们的请求。最简单的方法是过滤到你的跟踪器的域名。
你应该看到我们的lumetric.js加载，然后可能有查看事件和转化事件。
这里是funnelflux.com主页的一个例子：
此外，如果我点击"funnel"请求，我可以检查响应：
提示：点击Chrome中这个面板左下角的" { } "按钮来格式化内容。
在这里，我可以看到我们的跟踪器如何响应。它解析了一个访客ID，这意味着跟踪正常工作。如果不是，应该有一个错误消息，这意味着有些地方不太对。
问题2：你没有使用正确的转化代码
当你转到offer设置 > 转化跟踪时，有特定于该offer的JavaScript代码，即它在"p"值下包含了offer的ID。
如果你没有特别使用这段代码，那么你的转化事件就没有说"我想转化这个确切的offer"。
它可能发送了不同的值并造成混淆，或者它可能没有值。在这种情况下，FunnelFlux将尝试识别用户并转化最近访问的offer。
问题3：代码正在加载，但无法识别用户
这也是很可能的，如果你在上面的控制台/工具中检查转化代码响应，就会很清楚。
如果它说找不到漏斗/访客，那么很可能它已经失去了用户会话的跟踪。
这归结于客户端跟踪的挑战...如果它跳转多个页面才到达这里，并且在某个第三方网站上，那么它很可能需要依赖cookie（你的查看跟踪代码中是否启用了cookie？）。
这个限制没有简单的解决方法 - 它影响所有JavaScript跟踪，甚至包括Facebook和Google Analytics。这就是为什么服务器端跟踪通常更可靠。
如果这些是你控制的页面，那么你应该尝试确保在页面之间传递"vid"，这总是通过我们的重定向发生，我们的JS会自动尝试将这个访客/会话ID附加到动作URL。它基本上是试图通过URL手动跟踪cookie值。
如果当前URL或引荐URL中存在VID，我们的JavaScript将尝试找到它，但这并不总是在你的控制范围内。
关于这一点，如果你控制页面但使用页面之间的直接链接（不是通过跟踪器重定向的动作URL），请确保：
- 在所有页面上使用我们的查看跟踪JS
- 在点击链接上，添加
data-lum="action"属性
关于后一点，我们的JS也会看到这些链接并向它们添加数据以改善跟踪。所以你可以将：
<a href="/somepage">Some Link</a>
改为
<a href="/somepage" data-lum="action">Some Link</a>
如果你这样做，我们的JS会向这些链接添加数据，这样在下一个页面上，那里的JS就有更多上下文并更可靠。
你可以在funnelflux.com的主页上看到这一点 - 如果你检查我们的页面，你会看到我们的链接都附加了这些数据。但如果你检查页面源代码，这些值是不存在的！
页面源代码：
浏览器加载时发生的情况：
看到所有这些额外的东西是如何被添加的吗？那是我们的JS在工作，确保当你点击那个链接时，下一个页面有这个页面创建的所有上下文。
这就是为什么在所有页面上都有我们的JS非常有用，即使你不需要它并且全程使用重定向链接！